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Abstract. . .Implementation and results of an expen 
system used for scheduling session requests for the Systems En- 
gineering Simulator (SES) laboratory at the NASA Lyndon B. 
Johnson Space Center (JSC) arc discussed. Weekly session re- 
quests arc received from astronaut crew trainers, procedures de- 
velopers, engineering assessment personnel, software develop- 
ers, and various others who wish to access the computers, scene 
generators, and other simulation equipment available to them in 
the SES lab. The expert system under discussion is comprised of 
a data acquisition portion - two Pascal programs run on a per- 
sonal computer - and a CLIPS program installed on a minicom- 
puter. A brief introduction to the SES lab and its scheduling 
background is given. A general overview of the system is pro- 
vided, followed by a detailed description of the constraint-re- 
duction process and of the scheduler itself. Results from a ten- 
week trial period using this approach are discussed. Finally, a 
summary of this expert system’s strengths and shortcomings are 
provided. 


Introduction 


The Systems Engineering 
Simulator (SES) lab at the 
NASA Lyndon B. Johnson 
Space Center (JSC) provides the 
real-time engineering simulation 
capability needed to support 
various aspects of the Space 
Shuttle and the Space Station 
Programs. The SES has been 
used as a design and analysis 
tool throughout the Space 
Shuttle Program. 


Early in the Space Shuttle 
Program the SES was used to 
conduct conceptual design 
studies concerned with Orbitcr 
handling qualities, displays and 
controls, and orbital operations. 
As the Shuttle Program ad- 
vanced, the SES provided a test- 
bed in which flight software re- 
quirements (mainly guidance, 
navigation, and control) could be 
evaluated. The SES was also 


used extensively in supporting 
the design of the Remote Ma- 
nipulator System (RMS). In 
1984 the Manned Maneuvering 
Unit (MMU) was added to the 
SES. It has provided on-line 
support during several Space 
Shuttle missions, most notably 
the Solar Maximum repair mis- 
sion. 

More recently, the SES de- 
veloped the Orbiter/Space Sta- 
tion docking simulation. To 
develop the capability, reasona- 
bly sophisticated mathematical 
models of the Space Station 
were installed in the simulation. 
Mass properties, docking port 
geometry, RMS grapple fixture 
geometry, aerodynamics, atti- 
tude control system, reaction 
control system (RCS), and visual 
models are included in the 
mathematical models. Addition- 
ally, a complex Orbiter-to-Space 
Station Thruster plume impinge- 
ment model was developed and 
installed. The plume impinge- 
ment model produces reasonably 
accurate forces and moments on 
the Space Station that would 
result from any of the Orbiter’s 
38 primary RCS thruster exhaust 
plumes impinging on the Space 
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Station’s surfaces during an 
Orbiter approach. 

These are just some of the many 
functions that the SES has played 
a role in, and will continue to 
serve in, throughout the Space 
Shuttle and Space Station Pro- 
grams. Interested readers may find 
a more detailed description of the 
SES lab and its functions in [1]. 

SES Lab Equipment 

The SES lab is a large complex 
consisting of dedicated comput- 
ers, crew stations, computer-gen- 
erated imagery visual systems, and 
graphics systems. Minicomputers 
provide interfaces to the crew sta- 
tions, host the graphics systems 
which generate cockpit displays 
and real-time displays for test 
evaluators, and also provide the 
data recording function for the 
simulations. The mathematical 
models are also stored here. A 
large mainframe computer hosts 
the Space Shuttle entry and land- 
ing simulation and is used in con- 
junction with the Shuttle forward 
crew station (or forward cockpit). 

The SES crew stations include 
the aforementioned forward cock- 
pit, the Shuttle aft crew station (aft 
cockpit), a MMU crew station, 
and a Space Station crew station 
(cupola). All stations include flight- 
like displays provided by elec- 
tronic scene generators so as to 
make a simulation session as real- 
istic as possible to the participants. 
The crew stations are arranged in 


separate enclosures to facilitate 
parallel simulations. 

Approximately 15 lab equip- 
ment pieces - i.e., computers (and 
the math models), crew stations, 
scene generators, etc. - are avail- 
able to the lab users. 


Where An Expert System 
Comes In 

In earlier times and with a smaller 
lab, the SES lab manager gener- 
ated the weekly schedule manu- 
ally and fairly easily. However, 
the lab has grown over the years 
and so has the level of complexity, 
causing management to consider 
automating this task. 

Some examples of this com- 
plexity: Two parallel simulations 
may proceed during a scheduled 
session - one on the “A-Side" and 
one on the “B-Side” - as long as 
the equipment that each person 
has requested is mutually exclu- 
sive of the other’s hardware needs. 

Furthermore, an increased work- 
load in SES activities has recently 
forced the lab to expand its work- 
ing hours. Altogether, there are 76 
schedulable sessions in a week - 
( 1 5 days/week* 3 shifts/day * 2 ses- 
sions/shift * 2 parallel simulations/ses- 
sion ] + ( 2 days/weck * 2 shifts/day * 2 
sessions/shift * 2 simulaiions/scssion ] ). 

On the average, between 60-75 
session requests are submitted each 
week. Those who need the Aft 
Cockpit and/or the MMU for their 
simulations must run on the A- 
Side. Others who can accomplish 


their tasks without these equip- 
ment pieces can usually run on the 
B-Side. On infrequent occasions a 
requestor will ask for both sides 
simultaneously. 

Anotherfactor considered is the 
relative priority of each project. 
Certain recurring events such as 
astronaut crew training are given a 
high priority. Priorities of other 
projects such as conceptual design 
studies or software development 
work change weekly according to 
each project’s due date. The lab 
manager must be fully aware of 
each project’s status so as to make 
the most effective usage of the 
lab’s resources. 

Also, the time slots requested 
are considered whenever possible. 
There are those who would rather 
not work third shifts and/or week- 
ends. An attempt is made to ac- 
commodate these requests when 
feasible. Projects also dictate that 
work must be completed on/be- 
fore a given date, thereby making 
some sessions useless to the re- 
questor. 

Taking all these factors into con- 
sideration when scheduling is a 
monumental task for the SES lab 
manager, particularly when sched- 
uling is only one of the many 
functions that this individual is 
responsible for. Human errors can 
and do appear occasionally. The 
schedulercan inadvertently assign 
a lab equipment to two people si- 
multaneously, or some hardware 
that is unavailable or down for 
repair might get assigned. Some 
projects cannot run opposite oth- 
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ers. Because of the dynamic na- 
ture of the job, last-minute changes 
can cause a completed schedule to 
be entirely revamped. 

In summary, scheduling relies 
heavily upon human knowledge 
and experience. But humans are 
prone to make mistakes as well as 
subjective judgments. And because 
the job is very demanding, human 
scheduling experts are hard to come 
by and retain. It is for these rea- 
sons that an attempt has been made 
to automate the scheduling proc- 
ess. 


Overview of the 
system 

The system was developed to 
mimic the actual process used in 
generating a weekly schedule. The 
weekly requests are first reviewed 
for completeness and accuracy. 
Requests containing noticeably 
incorrect or inconsistent data are 
corrected or resolved by the lab 
manager. He also assigns a rela- 
tive priority to each request based 
upon his knowledge of the various 
projects’ upcoming due dates or 
the relative importance of the re- 
quested session. A data entry spe- 
cialist then keys the information 
from the request into a PC-based 
Pascal program, using both the 
mouse and the keyboard interfaces. 
The graphics/mouse interface is 
vital to this aspect of the system in 
that, with over 70 data fields asso- 
ciated with each request, the time 


spent on the data entry phase has 
been cut in half (versus using a 
keyboard interface only). 

After the requests have been 
entered and saved to disk, a sec- 
ond Pascal program is called to 
update the availability statuses of 
the various equipment found in 
the lab. For example, any equip- 
ment scheduled for preventative 
maintenance during a session can 
be marked as being “unavailable” 
for that session. 

From this second program (and 
assuming that both of the above 
tasks have been completed, result- 
ing in a request file and an equip- 
ment configuration file), one can 
then initiate that portion of the 
expert system that looks for 
“compatible” pairs of session re- 
quests - i.e., those pairs of users 
who can run simulations in paral- 
lel because the equipment requested 
by each is mutually exclusive of 
the other person’s (and they have 
both specified a given time slot as 
being “acceptable”). 

When two compatible requests 
are found, they are further con- 
strained by checking the Equip- 
ment Configuration File for equip- 
ment availability during a given 
time slot Should at least one equip- 
ment requested be found unavail- 
able, this compatible pair is no 
longer considered as a candidate 
for that time slot. This process 
continues exhaustively until all 
compatible pairs have been con- 
sidered for the time slots they 
deemed desirable. 


Those pairs having passed this 
constraining test are written to a 
file in CLIPS deffacts format. This 
will serve as an input file to a 
CLIPS program (the third and final 
one in the expert system), which 
does the actual assigning of com- 
patible pairs to sessions, by prior- 
ity. If a compatible pair cannot be 
found for a given session, then 
that time slot will be assigned to 
just one person who has the high- 
est remaining priority of those tasks 
being scheduled. Before complet- 
ing, this CLIPS program writes a 
schedule to a disk file, which is 
then printed out and reviewed by 
the manager. He has the final 
decision of whether to use any or 
all portions of it. 


Detailed 

description 

OF SYSTEM 

Start of the Scheduling 
Process 

The first constraint check com- 
pares a requestor’s list of equip- 
ment against the Equipment Con- 
figuration File for all schedulable 
sessions. If a person has requested 
an equipment that is not available 
for a given session, that requestor 
is not considered as a candidate 
for that session. But assuming that 
his/her requested equipment are 
all available, this single user is 
written to the CLIPS file (in the 
event that no pair can be found for 
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this slot), and the next constraint 
check is made - comparing that 
person’s equipment requests 
against the next person’s in the 
linked list data structure. 

User 1 ’s list of requested equip- 
ment is compared agains t U ser 2 ' s 
list. The check made is that of a 
Boolean Exclusive-Or function. 
That is, if User 1 has requested 
Equipment X and so has User 2, 
then these two users are no longer 
considered compatible. This might 
be referred to as a “hard" con- 
straint. Now, there also exists a 
case of a “soft" constraint, and it 
has to do with a user requesting 
one or more of the three scene 
generators (referred to as the ESG2, 
the POLY, and the CT6). Let us 
briefly look at this issue before 
continuing on with the scheduling 
process. 


“Soft” Constraints 


ered a “soft” constraint. Listed below are the different possibilities that 
must be considered when verifying a soft constraint between two users. 


(Requesting the same generator) 



User 1 

User 2 

Case 1 

NEEDS 

NEEDS 

Case 2 

NEEDS 

WANTS 

Case 3 

WANTS 

NEEDS 

Case 4 

WANTS 

WANTS 


Case 1 is the “hard” constraint example. If both requestors say they 
“need” it, then these two are considered incompatible. Cases 2, 3, 4, 
where “wants” is one of the choices specified, are examples of soft 
constraints and require further investigation. 

Consider the following example: User 1 and User 2 match up com- 
patibly on all equipment, excepting the scene generators. Assume all 
three scene generators are available. User 1 “needs” ESG2 and POLY. 
User 2 “wants” either the ESG2 or the POLY, but just one of the two 
is sufficient. In this case. User 1 and User 2 would be incompatible 
because if User 1 needs them. User 2 would be “locked out. 


There are situations where a 
user needs a specific scene gen- 
erator, in effect saying: “I’ve got 
to have the (ESG2/POLY/CT6) 
scene generator, or else 1 can’t do 
my job.” One reason for this is that 
not all scene generators are ca- 
pable of generating the desired 
scene for a simulation session. This 
again would be considered a hard 
constraint. 

But then there are occasions 
where any one of the three scene 
generators is acceptable to the 
requestor. “I don’t care which one 
you assign to me, just as long as I 
get one.” This would be consid- 


WhatifUser 1 “needs” ESG2 and POLY, and User 2 “wants” POLY 
or CT6? Now, they would be considered compatible, because User 1 
can be assigned his/her equipment, and User 2 can be assigned the CT6 
scene generator. 

As long as ONE of the scene generators not “needed” by User i is 
available and deemed as “wanted” by User j, then Users i and j are 
compatible, and this soft constraint is resolved. Similarly, for the case 
where both users “want” a scene generator and at least one of the two 
has requested TWO or more scene generators, then the soft constraint 
is resolved (our implicit rule is to assign just ONE scene generator if the 
requestor specifies “wants” and not “needs”). 

Cases 2, 3, and 4 above can be expressed in Boolean Algebra termi- 
nology. Using the following notation for these Boolean variables: 
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A, = ESG2 Requested by User 1 

A, = POLY Requested by User 1 
Aj= CT6 Requested by User 1 

B, = ESG2 Requested by User 2 
Bj = POLY Requested by User 2 
B, = CT6 Requested by User 2 
Compatible : Boolean; 


-A, = ESG2 Not Requested by User 1 
-A, = POLY Not Requested by User 1 
-A,= CT6 Not Requested by User 1 
~B, = ESG2 Not Requested by User 2 
~B 2 = POLY Not Requested by User 2 
-B, = CT6 Not Requested by User 2 


Case 2: User 1 “needs” and User 2 “wants”. Then - 
Compatible := (~A,&B,) OR (~A,&B 2 ) OR (~A 3 &B 3 ) 

or, to generalize: 

Compatible := OR(i, i=l,N) { } 

As long as “Compatible” evaluates to TRUE, User 1 and User 2 are 
compatible on this soft constraint. 

Case 3: User 1 “wants” and User 2 “needs”. Then - 
Compatible := (A,&~B,) OR (A 2 &~B 2 ) OR (A 3 &~B 3 ) 

or, to generalize: 

Compatible := OR(i, i=l,N) { A,&~B, } 

Case 4: User 1 “wants” and User 2 “wants”. Then - 
Compatible := (-A^B,) OR (~A 2 &B 2 ) OR (~A 3 &B } ) OR 
(A,&~B,) OR (A 2 &-B 2 ) OR (A 3 &~B 3 ) OR 
(A,&B 2 ) OR(A,&B 3 ) OR(A 2 &B,) OR 
(A^B,) OR(A 3 &B,) OR(A 3 &B 2) 

or, to generalize: 

Compatible := [ OR (i i=l,N) { -A.&B, } ] OR 
( OR (i issl,N) { A.&-B, } ] OR 
[ OR (ij i=l,N j=l,N i.NE.j) { A,&Bj ] 


Back to the Scheduling Process 


Assuming that User 1 and User 
2 have passed the first two con- 
straint checks, the last constraint 
check made in this program deter- 
mines that if either User 1 or 2 has 
requested an equipment, the Equip- 
ment Configuration File is checked 
to see if the equipment is available 


for this session. If it is, then User 1 
and User 2 (with their associated 
priorities and the session number) 
are written as a “compatible-pair” 
entry to a CLIPS-formatted def- 
facts file. This file will be the 
input file to the third and final 


(CLIPS) program in the expert 
system. 

This entire constraint-reduction 
process is repeated - that is, User 1 
is compared with User 3, User 1 
with User 4, and so forth - until all 
combinations have been exhausted. 
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Schedule Compatible Pairs 
for Available Sessions 


This third and final program is 
written in CLIPS, as mentioned 
earlier. The “deffacts” file created 
by Program 2 is opened/read. Also, 
the Request File created by Pro- 
gram 1 is read in; it contains the 
auxiliary request-related informa- 
tion - such as requestor’s name, 
phone number, activity descrip- 
tion, etc. - that is used for listing 
out the people scheduled for the 
various sessions. 

The program schedules sessions 
in order from the most desirable 
(first shift Monday through Fri- 
day) to the least desirable (third 
shift). Two deffacts, shown be- 
low, are used here. Deffact “next- 
session” contains the next session 
number to be scheduled, where 1 
= Session 1 on Monday, 2 = Ses- 
sion 1 on Tuesday, 8 = Session 2 
on Monday, etc. Deffact 
“sessionsjeft” is a list structure 
showing those remaining sessions 
to be scheduled, in the order speci- 
fied. After a session has been sched- 
uled, the “next-session” fact is 
modified to contain the left-most 
number from the “sessions_left” 
fact. Then, “sessionsjeft” is also 
changed to remove a session 
number from its list once it has 
been “moved” to “next-session.” 

When the final value (0) in 
“sessionsjeft” is encountered, the 
program halts. Note that third shift 
on weekends (numbers 34, 35, 4 1 , 
and 42) have been omitted from 
“sessionsjeft” because these time 
slots are currently not used. 


(next-session 1 Monday) 

(sessionsjeft 2 3 4 5 8 9 10 11 12 15 16 17 18 19 

6 7 13 14 22 23 24 25 26 20 21 27 28 29 

30 31 32 33 36 37 38 39 40 0) 


The general searching order is to: 

♦ find a compatible pair where both have the current 
highest priority, 

♦ find a pair where one of the two has the highest priority, 

♦ find just one person (leaving the other slot open for anyone who 
can use it) having the current highest priority, and 

♦ leave the slot open because no one remaining had specified 
this session as an acceptable choice. 

Also factored into these searching rules is a check to see if either one 
or both of the current pair being scrutinized were assigned to the last 
session as well. The reasons behind this are twofold: Those requesting 
multiple sessions will have a tendency toward wanting to work consis- 
tent hours that week (instead of first shift today, third shift tomorrow, 
etc), and second, this scheme tends to not schedule a multiple session 
requestor twice on any given day with a gap between sessions (first and 
third session, for example). A gap would require lab participants to 
work a non-contiguous eight-hour day. 
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r Results 

This system was run for a ten-week trial period. The criteria 
used for comparison was the number of requests assigned 
versus the total number requested that week. Shown below are 


the results. 

NUMBER 

NUMBER 

PERCENTAGE 

WEEK * 

ASSIGNED 

REQUESTED 

ASSIGNED 

Week 1 

45 

55 

81.8 

Week 2 

52 

59 

88.1 

Week 3 

54 

59 

91.5 

Week 4 

53 

58 

91.4 

Week 5 

47 

54 

87.0 

Week 6 

48 

54 

88.9 

Week 7 

49 

65 

75.4 

Week 8 

59 

76 

77.6 

Week 9 

55 

66 

83.3 

Week 10 

56 

71 

78.9 


These results are consistent with those obtained by 
manual scheduling before making forced adjustments. That 
is, a high percentage of the requests can be satisfied by assign- 
ing those with the highest priority to die slots they deemed 
acceptable. But to fit in the remaining requests, the lab 
manager must force-assign people to slots they did not spec- 
ify, or he may assign slots to requestors if they can forgo the 
use of equipment that is unavailable during that session. 


What was learned 

The approach taken towards 
the scheduling task had its strong 
points and its shortcomings. One 
positive aspect was that the high- 
priority requests were almost 
always scheduled, leaving the 
lower-priority requests to be as- 
signed manually by the lab man- 


ager. Another was that a multiple 
session requestor would often be 
assigned contiguous sessions as 
designed. And seldom did a proj- 
ect request get assigned non-con- 
tiguous slots within the same day. 

A negative point is that a user 
who requested sessions for two or 
more DIFFERENT projects that 
week was often assigned non-con- 


tiguous slots within a given day 
(no check was made to see if the 
same person was assigned to an 
earlier session that day). Also, the 
program found only one schedule. 
Perhaps better schedules could have 
been generated to fit in more re- 
quests, had some factor of ran- 
domness and a looping mecha- 
nism been introduced into the 
program. 

Another very influential aspect 
that became self-evident during 
the project was the importance of 
getting requestors to abide by the 
request submission deadline. Un- 
fortunately, some people at times 
would not know what their work- 
load for the following week was 
until the request deadline had 
passed. Hence, their requests of- 
ten came in late - typically up until 
four hours before a completed 
schedule was to be reviewed by 
NASA officials. With manual 
scheduling, one could make cer- 
tain allowances to accommodate 
the late entries. However, four 
hours leaves very little time for 
the CLIPS program to execute on 
a minicomputer, particularly with 
20 or more interactive users logged 
in at the time. 


Summary 

Because of the aforementioned 
problems, the CLIPS scheduler was 
eventually replaced by a FOR- 
TRAN program on a mainframe 
to utilize its CPU speed. Most of 
the problems encountered with the 
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CLIPS version have been addressed 
successfully in the new one. The 
names of users requesting time for 
different projects are now checked 
so non-contiguous slots within a 
day are not assigned to any user. 
Subject to the above criteria, com- 
patible pairs are randomly selected 
and assigned to a schedule slot. A 
completed schedule is then evalu- 
ated according to several grading 
factors, and the 10 schedules with 
the highest scores are always saved 
(and later printed at a specified 
timeout period). The lab manager 
now has a choice of which sched- 
ule to use as a starting base. 

One method of circumventing 
the late submission problem has 
worked with limited success. 
“Dummy” requests with the same 
priority and with the same typical 
equipment requested by those 
expected latecomers are entered 
to serve as place-holders. This 
allows the scheduler to be started 
up with more lead time than previ- 
ously permitted, thus yielding 
higher-quality schedules. 

Because of the constantly chang- 
ing requirements brought on by 
new projects, it is felt that it would 
be difficult, at best, to program in 
all the constraint checks that are 
needed The best that one can expect 
from the scheduler output is that it 
is just a starting base that will still 
require at least some human ma- 
nipulation to satisfy the constraints 
associated with that week's re- 
quests and to force-fit in any re- 
quests that the scheduler cannot 
handle. 
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